The present invention generally relates to data processing in a network communication system. The invention relates more specifically to methods and apparatus that provide automatic bi-directional quality of service treatment to network data flows.
A computer network typically comprises a plurality of interconnected entities that transmit (xe2x80x9csourcexe2x80x9d) or receive (xe2x80x9csinkxe2x80x9d) data frames. A common type of computer network is a local area network (xe2x80x9cLANxe2x80x9d) that generally comprises a privately owned network within a single building or campus. LANs employ a data communication protocol (LAN standard) such as Ethernet, FDDI, or Token Ring, that defines the functions performed by the data link and physical layers of a communications architecture (i.e., a protocol stack), such as the Open Systems Interconnection (OSI) Reference Model. In many instances, multiple LANs may be interconnected by point-to-point links, microwave transceivers, satellite hookups, etc., to form a wide area network (xe2x80x9cWANxe2x80x9d), metropolitan area network (xe2x80x9cMANxe2x80x9d) or Intranet. These internetworks may be coupled through one or more gateways to the global, packet-switched internetwork knows as Internet.
Each network entity preferably includes network communication software, which may operate in accordance with Transport Control Protocol/Internet Protocol (TCP/IP). TCP/IP generally consists of a set of rules defining how entities interact with each other. In particular, TCP/IP defines a series of communication layers, including a transport layer and a network layer. At the transport layer, TCP/IP includes both the User Data Protocol (UDP), which is a connectionless transport protocol, and TCP which is a reliable, connection-oriented transport protocol. When a process at one network entity wishes to communicate with another entity, it formulates one or more messages and passes them to the upper layer of the TCP/IP communication stack. These messages are passed down through each layer of the stack where they are encapsulated into packets and frames. Each layer also adds information in the form of a header to the messages. The frames are then transmitted over the network links as bits. At the destination entity, the bits are reassembled and passed up the layers of the destination entity""s communication stack. At each layer, the corresponding message headers are also stripped off, thereby recovering the original message which is handed to the receiving process.
One or more intermediate network devices are often used to couple LANs together and allow the corresponding entities to exchange information. For example, a bridge may be used to provide a xe2x80x9cbridgingxe2x80x9d function between two or more LANs. Alternatively, a switch may be utilized to provide a xe2x80x9cswitchingxe2x80x9d function for transferring information, such as data frames or packets, among entities of a computer network. Typically, the switch is a computer having a plurality of ports that couple the switch to several LANs and to other switches. The switching function includes receiving data frames at a source port and transferring them to at least one destination port for receipt by another entity. Switches may operate at various levels of the communication stack. For example, a switch may operate at Layer 2 which, in the OSI Reference Model, is called the data link layer, and includes the Logical Link Control (LLC) and Media Access Control (MAC) sub-layers.
Other intermediate devices, commonly known as routers, may operate at higher communication layers, such as Layer 3, which in TCP/IP networks corresponds to the Internet Protocol (IP) layer. IP data packets include a corresponding header which contains an IP source address and an IP destination address. Routers or Layer 3 switches may re-assemble or convert received data frames from one LAN standard (e.g., Ethernet) to another (e.g., Token Ring). Thus, Layer 3 devices are often used to interconnect dissimilar subnetworks. Some Layer 3 intermediate network devices may also examine the transport layer headers of received messages to identify the corresponding TCP or UDP port numbers being utilized by the corresponding network entities. Many applications are assigned specific, fixed TCP and/or UDP port numbers in accordance with Request For Comments (RFC) 1700. For example, TCP/UDP port number 80 corresponds to the Hypertext Transport Protocol (HTTP), while port number 21 corresponds to File Transfer Protocol (FTP) service.
Computer networks include numerous services and resources for use in moving traffic throughout the network. For example, different network links, such as Fast Ethernet, Asynchronous Transfer Mode (ATM) channels, network tunnels, satellite links, etc., offer unique speed and bandwidth capabilities. Particular intermediate devices also include specific resources or services, such as number of priority queues, filter settings, availability of different queue selection strategies, congestion control algorithms, etc.
Individual frames or packets can be marked so that intermediate devices may treat them in a predetermined manner. For example, the Institute of Electrical and Electronics Engineers (IEEE) describes additional information for the MAC header of Data Link Layer frames in Appendix 802.1p to the 802.1D bridge standard.
FIG. 1A is a partial block diagram of a Data Link frame 100 that includes a MAC destination address (DA) field 102, a MAC source address (SA) field 104 and a data field 106. According to the 802.1Q standard, a user_priority field 108, among others, is inserted after the MAC SA field 104. The user_priority field 108 may be loaded with a predetermined value (e.g., 0-7) that is associated with a particular treatment, such as background, best effort, excellent effort, etc. Network devices, upon examining the user_priority field 108 of received Data Link frames 100, apply the corresponding treatment to the frames. For example, an intermediate device may have a plurality of transmission priority queues per port, and may assign frames to different queues of a destination port on the basis of the frame""s user priority value.
FIG. 1B is a partial block diagram of a Network Layer packet 120 corresponding to the Internet Protocol. Packet 120 includes a type_of_service (ToS) field 122, a protocol field 124, an IP source address (SA) field 126, an IP destination address (DA) field 128 and a data field 130. The ToS field 122 is used to specify a particular service to be applied to the packet 120, such as high reliability, fast delivery, accurate delivery, etc., and comprises a number of sub-fields. The sub-fields may include a 3-bit IP precedence (IPP) field and three one-bit flags that signify Delay, Throughput, and Reliability. By setting the flags, a device may indicate whether delay, throughput, or reliability is most important for the traffic associated with the packet. Version 6 of the Internet Protocol (Ipv6) defines a traffic class field, which is also intended to be used for defining the type of service to be applied to the associated packet.
A working group of the Internet Engineering Task Force (IETF) has proposed replacing the ToS field 122 of Network Layer packets 120 with a one-octet differentiated services (DS) field 132 that can be loaded with a differentiated services codepoint (DSCP). Layer 3 devices that are DS compliant apply a particular per-hop forwarding behavior to data packets based on the contents of their DS fields 132. Examples of per-hop forwarding behaviors include expedited forwarding and assured forwarding. The DS field 132 is typically loaded by DS compliant intermediate devices located at the border of a DS domain, which is a set of DS compliant intermediate devices under common network administration. Thereafter, interior DS compliant devices along the path apply the corresponding forwarding behavior to the packet 120.
FIG. 1C is a partial block diagram of a Transport Layer packet 150 that preferably includes a source port field 152, a destination port field 154, and a data field 156, among others. Fields 152, 154 preferably are loaded with the TCP or UDP port numbers that are utilized by corresponding network entities.
To interconnect dispersed computer networks, many organizations rely on the infrastructure and facilities of Internet Service Providers (ISPs). For example, an organization may lease one or more T1 lines to interconnect various LANs. Each organization enters into a service-level agreement with its ISP. The service level agreements include one or more traffic specifications. The traffic specifications may place limits on the amount of resources that the organization may consume for a given price.
For example, an organization may agree not to send traffic that exceeds a certain bandwidth, e.g., 1 Mb/s. Traffic entering the service provider""s network is monitored to ensure that it complies with the relevant traffic specifications and is thus xe2x80x9cin profile.xe2x80x9d Traffic that exceeds a traffic specification, and is therefore xe2x80x9cout of profile,xe2x80x9d may be dropped or shaped or may cause an accounting change. Alternatively, the service provider may mark the traffic as exceeding the traffic specification, but allow it to proceed through the network anyway. If there is congestion, an intermediate network device may drop such marked traffic first in an effort to relieve the congestion.
A process executing at a network entity may generate hundreds or thousands of traffic flows that are transmitted across a network. Generally, a traffic flow is a set of messages (frames and/or packets) that typically correspond to a particular task, transaction or operation (e.g., a print transaction) and may be identified by various network and transport parameters, such as source and destination IP addresses, source and destination TCP/UDP port numbers, and transport protocol.
The treatment that is applied to different traffic flows may vary depending on the particular traffic flow at issue. For example, an online trading application may generate stock quote messages, stock transaction messages, transaction status messages, corporate financial information messages, print messages, data backup messages, etc. A network administrator may wish to apply a different policy or service treatment (xe2x80x9cquality of servicexe2x80x9d or xe2x80x9cQoSxe2x80x9d) to each traffic flow. In particular, the network administrator may want a stock quote message to be given higher priority than a print transaction. Similarly, a $1 million stock transaction message for a premium client should be assigned higher priority than a $100 stock transaction message for a standard customer.
Quality of service signaling mechanisms, such as RSVP and DiffServ (or IP Precedence) can be used by network applications to signal the network and get specific treatment for specific flows. However, such mechanisms only permit one-directional quality of service signaling, from the sender to the receiver. This is inadequate for many applications.
Consider as an example, an Internet Service Provider (ISP) that is handling video conference traffic from a server at the ISP to a remote client. When a video conference connection is established between the ISP""s equipment and the client, the ISP can set quality of service values for the outbound data flow that are appropriate to video conference traffic. However, processes for causing equipment in a remote network that contains the client to know that it is receiving video conference traffic, and for causing it to set quality of service values appropriately for traffic sent from the client to the server, are complex. These processes also do not scale well.
For example, if the client is connected through many edge network elements, then an appropriate QoS command must be configured on each and every edge network element. The classification of the flow may be dynamic so there is no way to preconfigure the edge devices to apply the right treatment to the other side""s flow. Further, even if the classification is static (e.g., based on the IP address of the server), it may scale poorly. If there are many servers, one must potentially place a command for each and every server on potentially each and every edge device. This requires an unreasonable amount of work.
Further, applications may run on hosts that have no inherent capability of setting quality of service values. In a network with such hosts, quality of service signaling is carried out by a network device that serves as a proxy for quality of service. The proxy, for example, generates RSVP messages on behalf of the application, or marks its packets using a pre-installed Access Control List (ACL). In some cases, the receiving device is not under the same control as the sending device, or there is no proxy, or there may be many receiving devices. In all these cases, establishing signaling for a flow in the reverse direction is complicated.
For example, in a one-to-many configuration, such as a server with many clients, in one current approach, current approaches may require configuring multiple ACLs on multiple edge devices. Some approaches might require configuring many different ACLs on each and every switch; potentially one ACL for each server for quality of service is required. This requires extensive, duplicative configuration work.
Another context presenting problems for current approaches is an ISP network, for example, an ISP network that provides virtual private network services, in which a first peer node is within the network and a second peer node is outside the network. The ISP may mark traffic outbound from the first node, for example, by creating and storing an appropriate ACL on the switch or router that is adjacent to the first node. However, for each such node the ISP would have to install a similar ACL on all network devices at the border or edge of the network and going into other ISPs. Further, these ACLs might need to be added and removed dynamically as network flows are created and stopped.
Based on the foregoing, there is a clear need in this field for a way to set quality of service values for packets transmitted in the network flow in both directions of a flow among a sender and a receiver.
There is a specific need for an approach whereby QoS may be established for a flow at a single network edge device and automatically enforced by all other edge devices, without separate, manual configuration work occurring at all the edge devices. Current approaches do not permit automatic, bi-directional application of quality of service values to network data flows in this manner.
There is a specific need for a mechanism, useful for a data flow that is carrying a bi-directional or symmetrical video conference call, with which quality of service values may be set for devices used only in the outbound route of the data flow.
The foregoing needs, and other needs and objects that will become apparent from the following description, are fulfilled by the present invention, which comprises, in one embodiment, a method of providing automatic bi-directional quality of service treatment of a network data flow. A network device located at the edge or border of a network, such as a router that is connected to another network, identifies incoming data flows that have packets set with quality of service treatment values. The quality of service treatments recognized by the network device may be IP precedence, DSCP marking of packets in the flow, an RSVP PATH message, etc. Upon identifying an inbound flow with quality of service treatment, the network device creates and stores, in its local memory, values that uniquely identify the flow and that tell the device how to treat packets of the same flow that are transmitted in the opposite or outbound direction. All packets of the same flow, regardless of flow direction with respect to the network device, are given a pre-configured quality of service treatment.
In one aspect, the invention provides a method of automatically applying a quality of service treatment to a network data flow, comprising the steps of receiving a network data flow comprising at least one message element that is associated with an outbound quality of service treatment value; creating and storing an inbound quality of service value in association with information identifying the network data flow; receiving one or more inbound message elements; determining that the inbound message elements are associated with the same network data flow; and applying the inbound quality of service value to the inbound message elements based on the stored information.
According to one feature, receiving a network data flow comprises receiving a network data flow comprising at least one message element that is marked with a DSCP value and wherein applying the inbound quality of service value comprises marking the inbound message elements with the DSCP value. A related feature is that receiving a network data flow comprises receiving a network data flow comprising one or more message elements that are marked with a DSCP value, and wherein applying the inbound quality of service value comprises retrieving the inbound quality of service value from a mapping of DSCP values to associated quality of service values, and adding the retrieved quality of service value to the inbound message elements.
In another feature, the creating and storing step comprises creating and storing a hash entry in a hash table that uniquely identifies the network data flow and that includes the inbound quality of service value.
Still another feature is that applying the inbound quality of service value to the inbound message elements based on the stored information comprises automatically generating an inbound RSVP PATH message for the flow when the inbound message elements include an RSVP PATH message. Yet another feature is that receiving a network data flow comprises receiving a network data flow comprising at least one message element that includes an RSVP PATH message, and applying the inbound quality of service value comprises marking the inbound message elements with an RSVP PATH message.
Other features and aspects will become apparent from the following description and claims.